/ScriptX/Documentation/HTML Files/language guide HTML/chars/cdreturn.gif)
#<#<Module Substrate>, #<Module ScriptX>, #<Module Scratch>
Scratch module. The title bar of the listener
window reads "ScriptX Listener in module Scratch."
It is not necessary to define a new module to use ScriptX. If
you do not define a module, your program compiles in the
Scratch module, the default module. This module
could just as easily have been called the "runtime" module in
that it is created automatically, "from scratch," every time
ScriptX runs, but cannot be saved. Any time you start running
ScriptX, your program is compiled in the Scratch
module until you explicitly declare that it is compiling in
another module, by using the in module
expression. If you are working in a user-defined module and
then select New Listener from the ScriptX
File menu, a new Listener starts in the
Scratch module.
The Scratch module is one of three instances of
ModuleClass that is created by the system. The
global function currentModule indicates which
module ScriptX is currently compiling in.
allInstances ModuleClass
currentModule()
In addition to the Scratch module, ScriptX
creates two system modules. The Substrate module
is the module in which all global names from the core classes
are defined and implemented. The ScriptX module
is the interface module for the Substrate module.
It is through the ScriptX module that names
defined in the substrate are exported to other modules,
including the Scratch module.
ScriptX or Substrate
modules. The ScriptX and Substrate
modules implement the
interface/implementation model, as described in the section "Organizing
Modules" on page 214.
The Scratch module is suitable for testing brief
scripts that are compiled from scratch each time they run. But
if you want to save a project you have compiled, so that it
can run in the Kaleida Media Player, it must be compiled and
saved in another module.
An authoring environment can potentially define other
"default" modules in addition to the ScriptX and
Scratch modules. For example, an authoring tool
could define new class libraries that are specific to some
environment, or accessories that allow you access to
platform-specific features. When you start up ScriptX in the
Listener, the compiler is placed into the Scratch
module. Other authoring environments may define a different
"working" module.
The ScriptX module is the standard interface
module which all other ScriptX modules and
authoring environments include. This module exports all
variable names in the ScriptX core classes, including names of
classes, system objects, generic functions, and global
variables. When you create a new module in which you plan to
implement ScriptX code (an implementation module), you should
import (use) the ScriptX module so that you have
access to the core classes.
in module at the top of each source file
that contains code for a given module. Everything in the file
should belong to and be compiled in that one module. In this
way, you can tell from looking at each source file which
module it belongs to.
This document is part of the ScriptX Language Guide, one of the volumes of the ScriptX Technical Reference Series. ScriptX is developed by the ScriptX Engineering Team at Apple Computer, successor to the Kaleida Engineering Team at Kaleida Labs, Inc.